Day 1｜AI 不是不會做，是你只說「做得好看一點」

安安，我是 ChiYu！

今年的第一篇，我想先從一句非常有 Vibe Coding 味道的 Prompt 開始。

這句話看起來有講需求、有講風格，甚至還很貼心地補了「好用」：

幫我做一個現代、漂亮、好用的工作區成員管理後台。

我在 2026 年 7 月 24 日把它交給 Codex Desktop 與 GPT-5，請 AI 產生一個能在瀏覽器開啟的靜態前端頁面。沒有補搜尋規則，沒有說明停用帳號的流程，也沒有偷偷提醒它記得處理手機版。

我想看看，只給「現代、漂亮、好用」，AI 到底會怎麼理解。

它沒有追問，開工速度倒是很快。Sidebar、摘要卡、搜尋、篩選、Data Table、分頁，常見的 SaaS 後台全家餐很快就端上桌：

圖 1：AI 根據模糊 Prompt 產生的第一版。所有帳號、信箱與資料都是虛構內容。

第一版後台外觀完整，互動是否真的能用？

有一說一，我第一眼沒有討厭它。

版面乾淨，資訊也排得像模像樣，AI 甚至主動補了三張摘要卡。假如驗收方式只有「截圖貼到群組，大家覺得像不像 SaaS」，它大概已經可以收工了。

但這是一個成員管理後台，不是後台形象照。

畫面裡既然有搜尋、有篩選、有停用帳號，我總得按按看。結果我只操作了三次，這個後台就開始露餡。

搜尋、篩選與停用只測三次，功能缺口全冒出來

我先在搜尋欄輸入 Aurora。

三筆資料一筆都沒少。

接著按下「篩選」，畫面沒有出現篩選條件，也沒有任何狀態改變。最後，我點了第一列的「停用」。

它的情緒非常穩定，完全不為所動。

這三次操作都是管理員真的會做的事。結果整理如下：

圖 2：畫面縮到 360px 後，頁面仍很有原則地維持 1180px。主要內容沒有重排，只是離開了使用者的視線。

桌面版至少還能看到一張完整的畫面，手機版就更直接了。左側 Sidebar 幾乎包辦整個 Viewport，真正要處理的成員資料被推到右邊。所謂手機版，現在連主要任務都進不了畫面。

我把剛才遇到的缺口標回桌面版，問題也就很清楚了：

圖 3：元件都出現了。每個紅框仍缺少行為、狀態與驗收條件。

看到這裡，我沒有辦法把責任全部推給 AI。

我的 Prompt 只交代「現代、漂亮、好用」。AI 確實完成了其中最容易展示的部分：外觀。至於搜尋比對哪些欄位、篩選有哪些條件、停用前要不要確認、失敗時怎麼辦，我一個字都沒說。

我給了三個形容詞，卻期待它自行補完一套產品規則。這筆帳算一算，真正漏寫需求的人好像還是我。

看得見搜尋框，卻說不清楚要 AI 修改哪一層

發現功能沒做之後，我的下一個念頭當然是叫 AI 修改。

問題是，我要改哪裡？

「搜尋沒反應」聽起來很清楚，但我要調整的是 Search Field、搜尋與篩選組成的 Pattern，還是 Data Table 的資料狀態？手機上的左側區域，是 Sidebar 縮壞了，還是整個 Layout 根本沒有重新規劃？

畫面就在眼前，我卻只能說：

那個可以搜尋的東西幫我做好一點。
那個左邊的選單手機版不要佔那麼多。
那個停用按鈕按下去要有反應。

這幾句不算錯，但每一句都留下一大段修改邊界給 AI 猜。猜錯的部分，通常就會變成下一輪修改的新驚喜。

這也是我今年想參加鐵人賽的原因。

這 30 天要解決的事：叫出 UI 元件名稱，也說清楚用途

Vibe Coding 讓不熟悉程式的人也能開始做網站。這很好，但當畫面真的出現後，新的問題也會跟著來：你看得出某個地方怪怪的，卻叫不出元件名稱；知道自己想要什麼感覺，卻說不清楚它要怎麼操作。

例如，一個「看起來像下拉選單」的東西，可能只是在既有選項裡選一個，也可能需要搜尋、允許多選，甚至可以建立新資料。外觀很像，工作完全不同。

我希望這 30 天結束後，Vibe Coder 至少能做到這些事：

• 看到一個東西時，知道它常見的名稱和用途。
• 分得出外觀相似、責任不同的元件。
• 跟 AI 說明自己真正想要的畫面與互動。
• AI 交出結果後，知道要操作什麼、檢查什麼。

因此，這不會只是 30 天的元件名詞整理。每遇到一組元件，我都會先放進實際情境，操作 AI 產生的畫面，再說明我接受或退回它的理由。名稱只是起點，最後還是要回到能不能用、能不能驗收。

這套能力不要求你先成為前端工程師。後端工程師、PM、獨立開發者，或只是想用 AI 做一個 Prototype，都可以從畫面上的任務開始。

今年的範圍也會收得很窄：只講 UI 元件。

後端、資料庫與商業邏輯當然重要，但那是另外幾座山。我們先把使用者看得到、摸得到，真的會按下去的東西弄懂。

為什麼這 30 天幾乎不談 Code？

先把範圍講明白：接下來 30 天，你幾乎看不到程式碼。

不是因為 UI 元件不需要 Code，剛好相反，是它的寫法實在太多了。

同一顆 Button，放進 Vue、React、原生 HTML、開源套件或現成模板，可能就是完全不同的寫法。有些專案還會透過相當邪門的 CSS 與 JavaScript，硬是拼出一顆外表正常、裡面另有乾坤的按鈕。只要最後真的能用，前端世界什麼事情都有可能發生。

如果我們從 Day 1 就開始比較框架 API，這個系列很快會變成前端門派大亂鬥。30 天寫完，大家也許記住了好幾種語法，卻還是不知道該叫 AI 做哪一種元件。

所以程式碼不會是這次的重點。我要處理的是更前面的問題：這個元件叫什麼、能做什麼、適合放在哪裡，以及怎麼確認 AI 沒有只做出外殼。

UI 元件也不是由某一個人替所有產品訂下唯一答案。很多名稱和使用習慣，是產品、設計系統與使用者長期磨合後留下來的做法；部分原生控制項與無障礙互動，則有更明確的規範。

你當然可以不照文章裡的方式設計。只要自己清楚，也能把操作結果和理由說給 AI 聽，採用不同做法完全沒有問題。

只是 AI 看過大量常見介面，它的第一個答案通常也會往大家熟悉的模式靠。你想做得不一樣，就得多說幾句、多試幾次，也要有心理準備：AI 很可能趁你沒注意，又偷偷把設計拉回它熟悉的樣子。

所以這 30 天會以常見、容易理解的 UI 設計為主，不刻意把每個元件做成高度客製化版本。先把通用語言學會，以後真的要打破規則，至少知道自己正在打破哪一條。

用 LumenDesk 串起 30 天，不把元件寫成字典

如果接下來每天只是「今天介紹 Button、明天介紹 Text Field」，讀到第十天，我自己可能都會開始懷疑人生。

所以我準備了一個虛構產品 LumenDesk。它是一套工作區管理服務，所有帳號與資料都是假資料，不會使用任何真實個資或校務內容。

接下來，我們會替它邀請成員、建立活動、整理導覽、處理危險操作和錯誤狀態。每個元件都會在一個真的需要它的情境中出場，而不是排隊上台自我介紹。

圖 4：每個階段補上一種判斷能力，最後再回到同一個 LumenDesk 案例。

今天這張第一版也會原封不動留到 Day 29。它不是黑歷史，是我們整個系列的基準答案。

「好用」無法驗收，先改寫成使用者任務

我不是說 Prompt 從此不能出現「漂亮」或「好用」。這些詞可以用來交代方向，只是不能單獨負責驗收。

畢竟「這頁要好用」沒有辦法直接測。兩個人都覺得自己做得很好用，最後還是只能坐在會議室裡互看。

不需要因此寫出二十頁需求文件。先把形容詞換成幾個能回答的問題，就已經差很多：

套回 LumenDesk，我可以先補成這樣：

工作區管理員要在成員清單裡找人、查看帳號狀態，必要時停用帳號。停用前要能取消；手機上至少要看得到成員、狀態和下一步操作。

這依然不是完整規格，但搜尋有沒有縮小資料、停用能不能取消、手機看不看得到主要操作，已經可以直接測了。大家終於不用再對著「好用」兩個字投票。

圖 5：規格開始描述任務、行為與狀態後，畫面才有可以驗收的契約。這不是 Day 1 已完成的改善版。

先不重做後台，請 AI 列出自行補上的假設

看到第一版後，最簡單的做法是再補一句：「幫我改好一點。」

這句話也最有機會開啟第二輪猜謎。

所以我今天不要求第二版，反而先請 AI 停手，把剛才替我決定的事情一項一項列出來。哪些是需求真的有寫，哪些是它根據常見後台自行補上的，沒有答案的地方就老實標記「待確認」。

如果你也拿到一張看起來完成、實際上不知道怎麼驗收的畫面，可以把下面這段換成自己的情境：

我要做一個成員管理頁，給工作區管理員使用。
他需要搜尋成員、用部門和帳號狀態篩選，必要時停用帳號。

先不要重做畫面。請列出目前版本中你自行假設的內容：

1. 搜尋會比對哪些欄位，輸入後何時更新結果？
2. 篩選有哪些條件，套用後如何顯示與清除？
3. 「暫停」和「停用」各代表什麼？
4. 停用帳號前後會出現什麼確認與回饋？
5. Loading、Empty、Error、沒有權限與 360px 手機版要怎麼處理？

不要使用真實個資。沒有被說明的地方，請標記為「待確認」。

這段 Prompt 不會立刻生出第二張漂亮畫面。它甚至比叫 AI 直接重做慢，因為我們終於要面對那些原本一句話帶過的問題。

但它會把畫面背後的假設攤開：搜尋比對什麼、停用代表什麼、手機版保留什麼。可以接受的留下，需要調整的重寫，根本沒決定的就先別假裝完成。

完整改善版會留到 Day 29。現在先別急著救這張畫面，它還得替我們工作 28 天。

模糊 Prompt 只產生外觀，這張後台還不能交付

寫到這裡，第一版的搜尋仍然不會動，篩選依舊沒有內容，手機版也還維持 1180px。

這是刻意保留的結果。Day 1 先保存模糊需求會得到什麼，以及我們為什麼無法驗收它；神奇 Prompt 今天不會登場。

我今天真正改掉的只有一件事：第一個問題從「這張畫面漂不漂亮」，換成「使用者能在這裡完成什麼」。

接著又有一個問題。

我要怎麼告訴 AI，現在想改的是搜尋框、搜尋與篩選組成的功能，還是整張成員管理頁？如果連修改對象叫什麼都說不清楚，需求寫得再長，也可能只是把模糊的話寫得比較多。

Day 2，我們先不碰這張畫面。

先把畫面裡這些「那個東西」，一個一個叫出名字。

參考資料

• W3C WAI：Labeling Controls（查閱：2026-07-23）：輸入控制項需要可辨識的標籤，並與控制項建立正確關聯。
• W3C WCAG 2.2：Understanding SC 3.3.2 Labels or Instructions（查閱：2026-07-23）：需要使用者輸入時，必須提供足夠的標籤或說明，讓使用者理解應輸入什麼。
• W3C WAI-ARIA APG：Alert and Message Dialogs Pattern（查閱：2026-07-23）：涉及重要確認的對話框，需要有清楚的動作選項與可預期的鍵盤操作。